Methods for establishing a connection between a first and a second device over a bridge connecting a havi-subnetwork to another subnetwork

ABSTRACT

The invention concerns methods for establishing a connection between a first and a second device in a network comprising a bridge device connecting a first sub-network to a second sub-network. According to a first embodiment, the method is characterized in that it comprises the steps, at the level of a device control module of the first device hosted by the bridge device, of: (a) receiving, from a stream manager, data permitting identification of a peer device control module of the second device; (b) determining whether the device control module and the peer device control module are of the legacy type and have a same device identifier; and (c) in the negative, deducing that the first and second devices are on different sub-networks; (d) in the affirmative, deducing that the first and second devices are on the second sub-network. According to a second embodiment, the stream manager provides the device control modules with more direct information. The invention also concerns a method seen from the point of view of the stream manager.

The invention concerns methods for establishing a connection between twodevices which may be on the same or on different subnetworks, e.g. aUPnP and a HAVi network. It applies in particular to the field ofdomestic communication networks.

The bridge's functions include representing HAVi software elements(device control modules and functional component modules, for example)on the UPnP network, and representing UPnP devices and services on theHAVi network.

According to the HAVi specification, each device on a HAVi network hasto possess a configuration memory, from which certain descriptive datacan be read (‘SDD’ data for Self-Describing Data’).

The proxy devices of the bridge representing the UPnP devices are notreal-world devices, and thus do not have such a configuration memory.

The patent application No. WO 0076131 filed in the name of THOMSONmultimedia on May 31, 2000 and published on Dec. 14, 2000 concerns adevice and method for bridging a HAVi (Home Audio/Videointeroperability) network and a UPnP (Universal Plug and Play) network.

The European patent application EP01402205.7 filed on Aug. 22, 2001 inthe name of Thomson Licensing SA also concerns a HAVi-UPnP bridge, wherethe representation of devices on each side of the bridge is slightlydifferent from the above PCT application.

The present invention concerns an improvement of the invention describedin the European patent application, in particular in the case when adevice of one sub-network wishes to establish a connection between twodevices connected to another sub-network.

Indeed, when e.g. an application of a HAVi device wishes to set up aconnection between two UPnP devices on the UPnP sub-network, such aconnection has to be set up directly between the two UPnP devices, andshould not comprise a first connection between the source UPnP deviceand the bridge, followed by a second connection between the bridge andthe sink UPnP device.

The invention concerns a method for establishing a connection between afirst and a second device in a network comprising a bridge deviceconnecting a first sub-network to a second sub-network,

-   -   characterized in that it comprises the steps, at the level of a        device control module of the first device hosted by the bridge        device, of:    -   (a) receiving, from a stream manager, data permitting        identification of a peer device control module of the second        device;    -   (b) determining whether the device control module and the peer        device control module are of the legacy type and have a same        device identifier; and    -   (c) in the negative, deducing that the first and second devices        are on different sub-networks;    -   (d) in the affirmative, deducing that the first and second        devices are is on the second sub-network.

According to a first embodiment of the invention, step (c) furthercomprises the steps of establishing a connection between the firstdevice and the bridge device.

According to the first embodiment, step (d) further comprises the stepsof establishing a connection between the first device and the seconddevice on the second sub-network.

According to the first embodiment, the method further comprises, withinstep (d), the step of determining whether the device control module orthe peer device control module is to carry out the connection of step(d).

According to the first embodiment, the connection of step (d) isestablished by the entity among the device control module or the peerdevice control module which represents a sink device of the connection.

According to the first embodiment, the second sub-network is of the UPnPtype and wherein step (c) comprises:

-   -   the step of instructing Connection Managers of the bridge device        and the UPnP device represented by the device control module to        prepare for connection;    -   the step of setting up a connection on the UPnP sub-network        between the bridge device and said UPnP device; and    -   the step of configuring an internal connection of the bridge        device to link the connection on the UPnP sub-network with a        connection on the first sub-network.

According to the first embodiment, the second sub-network is of the UPnPtype and the step (d) comprises:

-   -   the step of instructing Connection Managers of the UPnP devices        represented by the device control module and the peer device        control module to prepare for connection; and    -   the step of establishing a connection on the UPnP sub-network of        the two UPnP devices.

According to the first embodiment, the data received from the streammanager comprises a SEID identifier of the peer device control module.

Another object of the invention is a method for establishing aconnection between a first and a second device by a HAVi Stream Manager,characterized in that it comprises the steps of:

-   -   (a) determining identifiers of device control modules of the        first and second devices;    -   (b) inserting said identifiers into a message for instructing a        device control module to perform internal connections.

According to a first embodiment, the message is ‘Dcm::Connect’.

According to the first embodiment, the method further comprises the stepof

-   -   checking whether the device control modules are of the legacy        type and have a same device identifier, and only in the negative        reserving connection resources on the HAVi network.

According to a second embodiment, the method further comprises a step(c) of checking whether the device control modules are of the legacytype and have a same device identifier, and wherein, in the affirmativethe message instructs the device control modules to establish a non-HAViconnection, and in the negative the message instructs the device controlmodules to establish a connection between a device on the HAVi networkand a legacy device.

Another object of the invention is a method for establishing aconnection between a first and a second device in a network comprising abridge device connecting a first sub-network to a second sub-network,

-   -   characterized in that it comprises the steps, at the level of a        device control module of the first device hosted by the bridge        device, of:    -   (a) determining whether the first and second devices are on        different sub-networks or whether the first and second devices        are on the second sub-network; and    -   (b) in the first case, establishing a connection directly        between the first and the second device; and    -   (c) in the second case, establishing at least a connection        between the bridge and the second device.

Other characteristics and advantages of the invention will appearthrough the description of a non-restrictive embodiment, explained withthe help of the enclosed figures, among which:

FIG. 1 is a block diagram of a network comprising a HAVi-UPnP bridgedevice.

FIG. 2 is a block diagram of the network of FIG. 1 comprising a HAVidevice but before connection of a UPnP device.

FIG. 3 is a block diagram of the network of FIG. 4 during theannouncement phase of a UPnP device.

FIG. 4 is a block diagram of the network of FIG. 5 after creation of aDCM and of an FCM for the UPnP device.

FIG. 5 is a flowchart of the processes carried out by a Stream Managerand a DCM according to a first embodiment of the invention.

FIG. 6 is a block diagram of a network showing certain steps of themethod according to the first embodiment in the case of establishment ofa connection between two UPnP devices by a HAVi device.

FIG. 7 is a block diagram of the network of FIG. 6 in the case aconnection is established through the bridge device.

FIG. 8 is flowchart of the processes carried out by a Stream Manager anda DCM according to a second embodiment of the invention.

According to the present embodiment, a bridge device links a HAVinetwork and a UPnP network. HAVi stands for ‘Home Audio Videointeroperability’ and defines a software stack for controlling a homenetwork, especially based on IEEE 1394 busses. The current version ofthe HAVi specification is v1.1, published May 15, 2001 and availablefrom HAVi, Inc., 2691 Bishop Drive, Suite 275 San Ramon, Calif. 94583,USA. UPnP stands for ‘Universal Plug and Play’ and also provides anetwork control software stack, based on the Internet Protocol (IP). TheUPnP specifications or draft specifications can be obtained from theUPnP forum managed by Microsoft Inc.

Be it in a HAVi network or a UPnP network, applications and otherelements must be able to determine available functionalities.

In a HAVi network, a functionality is represented by a software elementcalled FCM (Functional Control Module). Hierarchically speaking, a FCMis always contained in a DCM (Device Control Module), representing adevice. A DCM can contain more than one FCM (for example a DCMrepresenting a digital VCR contains a Tuner FCM and a VCR FCM). There isonly one DCM for each device.

In a HAVi network, if a software element wants to offer itsfunctionality to the network, it has to register itself with a localsoftware element called the ‘Registry’. When an FCM is created (it canbe at device boot time or at run time—e.g. download of a DCM controlunit or ‘DCU’), it registers itself in the Registry of its own device.

When an application wants to know which services are available in thenetwork, it sends a query to all Registries of the network.

Furthermore, a system of events exists for software elements createddynamically while the system is running. The Registry can make use oftwo events in order to announce the registration or removal of asoftware element: NewSoftwareElement (to indicate that a softwareelement has just been registered) and GoneSoftwareElement (to indicatethat a software element has just been unregistered). No polling isnecessary in the HAVi network.

If a software element is newer than a HAVi Registry (i.e. the softwareelement is of unknown type), it will still be recognized and shown as anew functionality on the HAVi network.

UPnP does not integrate a notion similar to the HAVi Registry.Nevertheless, in a UPnP network, services of devices may be announced onthe network. For this purpose, UPnP uses ‘HTTP over UDP for multicast’(HTTPMU). It is also possible for an application to search for a serviceon the network. The service discovery protocol is SSDP (Simple ServiceDiscovery Protocol). It can be combined with the GENA protocol (GeneralEvent Notification Architecture) for event notification. When anapplication wants to know which services are available, it sends a SSDPdiscover multicast message. The services which match the request have tosend back a response in unicast mode (HTTPU). The query can be verybroad (e.g. all services) or more limited (e.g. a certain type ofservice).

When a service is new on the network, it has to send a GENA-SSDP ‘alive’multicast message to announce its presence.

The alive message and the discover response message contain an age limit(‘max-age’) field. The maximum age field represents, in seconds, thevalidity of the service. If the service is still present after thistime, another alive message must be sent by the service (or anotherdiscover query is made).

In UPnP networks, control is carried out using Simple Object AccessProtocol (SOAP) messages.

The role of the bridge device is to connect both networks in such a wayas to translate messages from one side to the other, in order to enableany device of one network to communicate with any device of the othernetwork. The bridge should also be able to pass streams.

FIG. 1 gives an example of a HAVi network comprising a HAVi device 1connected to an IEEE 1394 bus 2, this HAVi network being connected to aUPnP network comprising a UPnP device 3 connected to an IP net 4, bothnetworks being linked by a bridge device 5. The bridge 5 comprises aHAVi protocol stack, an IP protocol stack, as well as software forcarrying out the translation or mapping of control messages, events,streams, . . . from one network to the other.

As described in the European patent application cited in theintroduction, a UPnP device is represented by a HAVi DCM, while a UPnPservice is represented by a HAVi FCM within the DCM representing theUPnP device linked to the service. Conversely, a HAVi DCM is representedby a UPnP device and a HAVi FCM is represented by a service associatedwith the device representing the DCM containing this FCM. The softwareelements created by the bridge are called ‘proxy’ software elements inwhat follows.

It is the bridge's function to represent devices as appropriate on eachnetwork: for each DCM or FCM on the HAVi network, it will create a UPnPdevice or a UPnP service. Conversely, for each UPnP device, respectivelyservice, the bridge creates a HAVi DCM, respectively FCM.

The bridge device is responsible for updating the representation of eachnetwork whenever a service, device, FCM or DCM is added or removed.

Depending on the configuration of each network, a bridge may manageseveral HAVi DCMs representing UPnP devices. It may also manage its ownDCM, since the bridge device may itself have a function other than itsbridge function. For example, the bridge function can be included in adevice such as a television receiver or a satellite decoder.

According to the HAVi specification and in conformity with the IEEE 1212standard, each HAVi device—which is a IEEE 1394 device—comprises aconfiguration memory. HAVi and IEEE 1394-2000 define a number ofparameters held in this memory. The parameters defined by HAVi arecalled self-describing data, or ‘SDD’, and may be read by anotherdevice. DCMs of the bridge representing UPnP devices do not representreal IEEE 1394 devices, and thus do not have a configuration memoryconforming to HAVi/IEEE 1394 which could contain SDD data.

In order to avoid this issue, DCMs created by the bridge to representUPnP devices are declared as legacy devices (‘LAV’ or Legacy Audio/Videodevices). These devices, which may or may not be IEEE 1394 devices, areconsidered as not being HAVi compliant, and are thus not expected tocontain SDD data. The nature of the DCM can be recognized by othersoftware elements using a function of the DCM application programmableinterface (API) called DCM::GetDeviceClass.

According to the HAVi specification, a DCM or FCM registers itself withits local Registry. During the registration, the DCM provides a certainamount of information, among others a data structure called TargetID,which indicates whether the registering software element is a device(DCM), a functional component of a device (FCM) or an applicationmodule. In the first two cases, the TargetID data structure alsoindicates whether the DCM or FCM is compliant with the IEC 61883standard which among other things defines the transport of isochronousstreams (e.g. audio and video streams) over a IEEE 1394 network. No twoTargetID data structures are to be the same.

The HAVi specification requires that the TargetID structure contain aglobal unique identifier (‘GUID’) which is a 64-bit quantity identifyinguniquely a IEEE 1394 device. This GUID identifier is stored in adevice's configuration ROM and is persistent over network resets. Withinthe context of streaming, the GUID given in the target ID identifies thephysical HAVi device to which the stream is to be sent or from which thestream is to be received. For certain device types, this may not be thehost device of the DCM associated with the stream source or sink devicebut the final target device GUID.

DCMs representing UPnP devices do not have an own GUID identifier.However, as the bridge will also send to the HAVi network streamsreceived from the UPnP network, or receive streams from HAVi devices tobe passed on to UPnP devices, these DCMs representing UPnP devices haveto use the bridge's GUID identifier in their TargetID data structure.

Being in the home network environment, the bridge may typically bedesigned to send or receive and process audio and video streams,independently from its function as a bridge between the HAVi and theUPnP networks. It then has its own DCM, and this DCM will be of the typecompliant with IEC 61883. During its registration, the DCM of the bridgeitself will use its own GUID identifier.

In such a case, the device type of a DCM representing a UPnP devicecannot be a DCM compliant with IEC 61883, because this would result ofhaving two identical TargetID data structures in the HAVi network. Evenif the bridge's own DCM were not of the DCM_(—)61883 type, the sameproblem occurs if the bridge is to handle more than two DCMs for UPnPdevices.

DCMs of UPnP devices are declared as non-61883 DCMs. In this case, theTargetID data structures of these DCMs still contain the bridge's GUIDidentifier (the bridge being the host of these DCMs), but the TargetIDsare distinguished by a further parameter, which is an identifierinternally attributed to each DCM by the bridge.

The fact that the UPnP devices are shown as non-61883 devices on theHAVi side of the network does not mean that these devices may not sendor receive streams, only that these streams are not necessarilycompliant with IEC 61883.

In a similar fashion, proxy FCMs representing UPnP services are declaredas non 61883 FCMs.

As mentioned, the HAVi specification defines five different values forthe target software element type (DCM_(—)61883, DCM_NON61883, FCM61883,FCM_NON61883 and AM). As a variant embodiment solving the above problem,additional target types are defined:

DCM_PROXY or DCM_NON1394—identifies a DCM as representing a UPnP device(or a device on another non-HAVi network)

FCM_PROXY or FCM_NON1394—identifies an FCM as representing a UPnPservice (or a service or functionality on another non-HAVi network)

On the UPnP side, such a problem does not exist, since the physicaldevice is represented with a root device, which can contain severaldevices and services.

When it receives an event that a new proxy DCM or FCM has been createdfor a UPnP device or service, a HAVi application may want to obtainadditional information regarding such a DCM or FCM. The reverse is alsotrue, when a UPnP device or service is informed of a new proxy device orservice handled by the bridge.

For this purpose, the bridge assembles information concerning each HAViDCM or FCM or UPnP service or device for which it creates a proxy. Thisinformation is assembled before announcement of the creation of theproxy software element.

The bridge carries out the following steps:

-   -   (a) For a new HAVi software element, the bridge requests the        element's attributes from the Registry (using the        Registry::RetrieveAttributes function).

For a new UPnP software element, the bridge has received a descriptionof the software element through the simple service discovery protocol‘alive’ message mentioned earlier. This description is a universalresource locator (URL) written in XML, and is, according to the presentembodiment, parsed by the bridge in order to extract all relevantinformation.

-   -   (b) The bridge creates the new proxy software element.    -   (c) The bridge sends an event to announce the availability of        the proxy software element, using the ‘NewSoftwareElement’ event        message on the HAVi network (for a proxy representing a UPnP        software element) or by using a ‘ssdp::alive’ multicast message        on the UPnP network (to announce a proxy for a HAVi software        element). In conformity with UPnP, this multicast message is to        be reiterated periodically.

The event mapping is given in Table 1: TABLE 1 HAVi UPnPNewSoftwareElement (Registry) ssdp::alive This event gives the SEID ofthe This multicast message gives the type new software element(s). Theof the new entity and the URL for its logical action after receivingsuch complete description (written in an event is a XML). So the nextlogicalaction is Registry::RetrieveAttributes on a HTTP GET call on thisURL. each SEID in order to have more So there is one ssdp::alive messageinformation about the software for each entity (root device, device,element. service) GoneSoftwareElement (Registry) ssdp::byebye This eventgives the SEID of the If the entity cannot send this software elementswhich message (plug off), the availability unregistered. of the entitywill end with the expiration of the ssdp::alive polling timer.

FIGS. 2 to 4 illustrate the process triggered at the bridge byconnecting a UPnP device to the UPnP network. In the initial network ofFIG. 2, only HAVi device 1 is connected to the HAVi network, and nodevice is connected to the IP network. The HAVi device is represented bythe bridge to the UPnP network as a proxy device 15, comprising a proxyservice 16 and a proxy Connection ManagerConnection Manager 10. For theclarity of the explanation, FIGS. 3 to 5 do not show proxy softwareelements corresponding to the HAVi device on the UPnP side of thebridge, unless required for the explanation.

As illustrated by FIG. 3, a UPnP device 3, in this case a UPnP VCR, isconnected to the IP network 4. The bridge 5 is notified of thisconnection via the SSDP protocol. The bridge then analyzes the XMLdescription of the device and discovers that the newly connected deviceis a VCR device including a VCR service.

As illustrated by FIG. 4, the bridge creates a HAVi DCM 8 and a HAVi VCRFCM 9 as proxy software elements, in order to simulate the UPnP VCRdevice and service. The two new HAVi software elements then request aSEID identifier from the bridge's Messaging System (‘MSG’ in FIG. 4) andregister with the bridge's Registry (‘Reg’). This registration causesthe Registry to send a NewSoftwareElement event over the HAVi network.

Stream establishment between two UPnP devices by a HAVi application isillustrated by FIGS. 5 to 7. FIG. 5 is a flowchart of the overallprocess carried out by the Stream Manager and the DCMs. FIGS. 6 and 7are block diagrams of a network and respectively illustrating the casewhere a HAVi application establishes a connection between two UPnPdevices and the case where the connection is established between a HAVidevice and a UPnP device. References for the control by certain elementsof other elements and of connections used in relation with FIGS. 6 and 7have been indicated also in FIG. 5, which presents the overall process.

In addition to the elements of FIG. 1, the network of FIGS. 6 and 7further comprises a second UPnP device 18, comprising a ConnectionManager 19. This second UPnP device is represented by a proxy DCM 20 onthe HAVi side of the bridge 5. UPnP device 18 is for example a display,and consequently a corresponding FCM 21 is created by the bridge. HAVidevice 1 further comprises an application 17.

The case of FIG. 6 will be treated first. The differences with the caseof FIG. 7 will then be indicated.

In the case of FIGS. 6, the application 17 of device 1—for example auser interface—calls the ‘FlowTo’ function of its Stream Manager (SM),which is the software element in HAVi in charge of establishing streams.The parameters of the FlowTo function call are identifiers of the plugsof the source and sink FCMs. This information is provided in datastructures called ‘FcmPlug’. The FCMs to be connected (in this case theproxy FCM of the UPnP device 3 and the proxy FCM representing the UPnPdevice 18) are identified using ‘TargetID’ data structures, which havealready been mentioned. In the example of FIG. 6, the TargetID of thesource and sink plugs indicate the GUID identifier of the bridge.

As an example, a connection is to be established from the source FCM 9to the sink FCM 21.

The Stream Manager triggers the required internal plug connections atthe level of the involved proxy DCMs and FCMs of the bridge, using‘DCM::Connect’ function calls (these connections internal to the DCMswill not be described in more detail). The Stream Manager checks whethera connection on the HAVi network is to be made or not, by verifyingwhether the DCMs which it calls are of the legacy type (LAV) and whetherthey are in the same device (i.e. whether they have the same GUID). TheStream Manager does not establish connections between software elementswithin a same device: this is up to the device itself. In the presentcase (FIG. 6), no reservations on the HAVi network are required, so theStream Manager does not make reservations of the IEEE 1394 isochronousresources and does. not update the IEC 61883 plug control registers ofthe devices involved, steps -it would take if a HAVi device wereinvolved in the connection.

To avoid having the bridge (in the form of the proxy DCMS) establish afirst connection between itself and UPnP device 18 and a secondconnection between itself and UPnP device 3, a called DCM (or anotherentity of the bridge to which this responsibility may be transferred)has to check whether both devices referred to in the DCM::Connect callit received are on the same side of the network or not. If this is thecase, then a direct connection has to be established between the twodevices on that one side, as shown in FIG. 6. Else, the DCM has tobehave as shown in FIG. 7.

In the current version of the HAVi specification, the DCM::Connectfunction call does not contain enough information to enable the calledDCM to determine whether the other DCM involved corresponds to a HAVidevice or a UPnP device. This function call only contains addresses ofsource and destination plugs internal to the DCM (e.g. for a connectionbetween the FCM and its DCM or between two FCMs inside the same DCM).

According to the present description, the Stream Manager transmits to aDCM information enabling it to determine whether it has to set up aconnection or not, and in the affirmative, which devices are to beconnected (i.e. either two UPnP devices or a UPnP device and thebridge).

According to a first embodiment, a new parameter is added to theDCM::Connect function call. The new parameter is:

-   -   in SEID PeerDcmSeid

This parameter represents the SEID identifier (comprising the device'sGUID identifier and a local handle) of the other DCM of the connection.

The proxy DCM receiving the function call (in step E61 of FIG. 6), forexample proxy DCM 20, then proceeds as follows:

-   -   (a) It checks whether the other DCM (e.g. 8) corresponds to a        UPnP device or not. According to the present embodiment, the        bridge maintains a table listing the correspondence between the        IP address and the SEID of each UPnP device, and the DCM checks        whether the SEID it received in the DCM::Connect function call        is present or not. In the affirmative, it knows that the other        DCM is a proxy DCM, and that a connection is to be set up        directly between two UPnP devices. According to a variant of the        present embodiment, the proxy DCM receiving the DCM::Connect        function call uses the received SEID to call the corresponding        DCM using a DCM::GetDeviceClass function call. If the call        returns the information that the other DCM is of the legacy type        (LAV), then the proxy DCM knows that this other DCM is also a        proxy of a UPnP device, if in addition this other DCM has also        the same GUID identifier, i.e. that of the bridge in the present        embodiment;    -   (b) If it has been determined that a connection needs to be set        up between the two UPnP devices represented by the proxy DCM 20        having received the DCM::Connect function call and the proxy DCM        8 identified by the SEID—and this is the case for the example of        FIG. 6—then the DCM 20 which received the DCM::Connect function        determines whether itself or the other proxy DCM is to set up        the connection on the UPnP network. Indeed, both proxy DCMs 8        and 20 will have received a DCM::Connect function call from the        Stream Manager. Only one should trigger the connection set-up on        the UPnP network. According to the present embodiment, the proxy        DCM representing the sink device carries out the set-up, by        acting as UPnP User Control Point and sending appropriate        messages (i.e. ‘PrepareForConnection’) to the Connection        Managers 11 and 19 of devices 3 and 18 respectively (step E62 of        FIG. 6). The User Control Point also sets up the IP connection        (step E63 of FIG. 6).

By recognizing that the connection is set up between two UPnP devices,the DCMs 8 and 20 also recognize that no connection is required betweena plug on the HAVi interface of the bridge and a plug on the UPnPinterface.

FIG. 7 illustrates the case where the connection between devices crossesthe bridge. For example, a connection is to be established between theDCM 7 of the HAVi device 1 and the UPnP device 3. The checks made by theStream Manager and the DCMs remain the same as above. Stream Managersends DCM::Connect calls to DCM 7 and DCM 8, representing the UPnPdevice 3 (step E71). The Stream Manager determines that a connection isrequired in the HAVi network between device 1 and the bridge and sets upthis connection (step E72). DCM 8 determines that the DCM 7 is not aproxy DCM having the same GUID as itself, so it instructs the ConnectionManagers 10 and 11 to prepare for a connection using‘PrepareForConnection’ messages (step E73), establishes the IPconnection (step E74) and the connection internal to the bridge (stepE75).

According to a second embodiment of the invention, a new function iscreated in the Application Programmable Interface of the HAVi DCMs, inorder to transmit certain information from the Stream Manager to theDCMs. This new function is used by the Stream Manager in the case wherethe connection to be established between two devices on a remotesub-network, such as the UPnP sub-network. According to this secondembodiment, this function is distinct from the DCM::Connect function,which remains as defined by HAVi. The Stream Manager determines whetherthe connection is a cross-bridge connection or a pure sub-networkconnection, and sends an appropriate function call to the DCMs.

According to this second embodiment, the new function has the followingformat: Status Dcm::Non1883Connect ( in SEID caller, in SEID sourceDcm,in Plug sourcePlug, in SEID sinkDcm, in Plug sinkPlug)The sourceDcm and sinkDcm parameters represent the SEIDs of the sourceand sink DCMs.

The sourcePlug and sinkPlug parameters are the DCM plugs of the sourceand sink devices. The call is to be sent to the source and sink DCMs bythe Stream Manager. The sink DCM will be in charge of setting up theUPnP connection. The Stream Manager analyzes the DCMs/FCMs involved inthe connection to determine whether a connection is required on the HAVisub-network or not, this not being the case as before when the DCMs areof the LAV type and have same GUID. A sink proxy DCM receiving aDcm::Connect function call knows that it has to set up the streambetween the bridge device and the UPnP device. If it receives aDcm::Non1883Connect function call, it knows that i has not to set up theUPnP stream between the UPnP device and the bridge, but between the twoUPnP devices. A source proxy DCM receiving a Dcm::Connect knows that ithas to setup the stream between the UPnP device and the bridge device.If it receives the Dcm::Non1883Connect, it knows that it has nothing todo but update the status of its plugs.

According to this second embodiment is that less burden is placed on theDCMs concerning decision taking, since: by issuing different functioncalls depending on the task to be performed, the Stream Managercentralizes some of this decision making.

According to a third embodiment of the invention, the Stream Managerdoes not transmit to a proxy DCM information concerning the peer DCM ofa connection to be established. The proxy DCM itself requests thatinformation, as follows:

-   -   (a) When the proxy DCM receives a Dcm::Connect function call as        defined by the HAVi specification, it positively acknowledges        this call, although it does not carry out any of the steps        required to set up the requested connection.    -   (b) The proxy DCM waits for the Stream Manager to issue a        message indicating that the connection has been created        (‘connection added’ event). Information concerning this        connection, including the identity of the peer DCM, will then be        available at the Stream Manager.    -   (c) The proxy DCM requests information concerning the connection        using the ‘SM::GetConnection’ function call as defined by the        HAVi specification.    -   (d) The proxy DCM checks whether the peer DCM is a 5 LAV of the        bridge, and then acts as above to set up either a connection        between UPnP devices (if it is the sink DCM) or a connection        between the bridge and a UPnP device.        The first two embodiments are preferred over the third one,        because the Stream Manager is made to believe that a connection        has been established, although this is not true.

Although the embodiments have been described in relation with a isbridge between a HAVi network and a UPnP network, the processesdescribed can be used just as well to establish connections between LAVtype devices hosted by a same HAVi device. This host device serves as a‘bridge’ between the HAVi network and the network of devices representedby legacy type DCMs (which may comprise a single legacy device).

Moreover, the invention applies also to the establishment of connectionswhen more than two sub-networks are connected to a same bridge. The sameAPI amendments described above can be applied in such a case. The bridgedevice contains data which indicates for each proxy DCM SEID thesub-network to which it belongs, and the address of the proxied deviceon the sub-network. For example, the third sub-network may be of the PLC(Power Line Control) type. A HAVi Stream Manager may then establish aconnection between e.g. a PLC device and a UPnP device, across thebridge, or between two devices on any of the sub-networks. Othercombinations are of course also possible.

What has been described above concerns the problem appearing when a HAViStream Manager tries to establish a connection between two UPnP devices.On the other hand, when a UPnP device establishes a connection betweentwo HAVi devices, this problem does not appear.

When a connection crossing the bridge is initiated by a UPnP device, thefollowing steps are taken: a Control Point (UPnP controller) invokes the‘ConnectionManager::PrepareForConnection’ command on both source andsink to establish a connection. This command is sent to the UPnP deviceand to the bridge device. When the bridge device receives such acommand, it makes a FlowTo call to its Stream Manager to establish a61883 connection between the target device and the proxy DCMrepresenting the involved UPnP device (this proxy DCM has a TargetIDwith the GUID of the bridge device). On the IP side, the protocol willbe IP based (http, rtsp, etc), and on the HAVi side it will be IEC61883based.

This method can also be applied to a stream established on the HAVi sideby a UPnP application. The Connection Managers will both be on thebridge device. The CM::PrepareForConnection function comprises aparameter called PeerConnectionManager, identifying the peer ConnectionManager of the connection to be established and indicating to eachConnection Manager whether the stream crosses the bridge or not,and-what parameters to put in the FlowTo call (the bridge FcmPlug oranother HAVi FcmPlug).

UPnP specifies for IEC61883 based streams (which is the case when thespecified protocol is HAVi or IEC61883) that the sink device isresponsible for the connection. So the Connection Manager of the sinkproxy will be in charge of the IEEE 1394 connection if the stream ispurely one the IEEE1394 network. Moreover, the Connection Manager of theproxy (sink or source) will be in charge of the IEEE 1394 side of thestream if the stream crosses the bridge.

DCM::Connection ManagerConnection ManagerConnection ManagerConnectionManagerDCM::Connection ManagerConnection Manager

1. Method for establishing a connection between a first and a seconddevice in a network comprising a bridge device connecting a firstsub-network to a second sub-network, wherein it comprises the steps, atthe level of a device control module of the first device hosted by thebridge device, of: (a) receiving, from a stream manager, data permittingidentification of a peer device control module of the second device; (b)determining whether the device control module and the peer devicecontrol module are of the legacy type and have a same device identifier;and (c) in the negative, deducing that the first and second devices areon different sub-networks; (d) in the affirmative, deducing that thefirst and second devices are on the second sub-network.
 2. Methodaccording to claim 1, wherein step (c) further comprises the steps ofestablishing a connection between the first device and the bridgedevice.
 3. Method according to claim 1, wherein step (d) furthercomprises the steps of establishing a connection between the firstdevice and the second device on the second sub-network.
 4. Methodaccording to claim 3, further comprising, within step (d), the step ofdetermining whether the device control module or the peer device controlmodule is to carry out the connection of step (d).
 5. Method accordingto claim 4, wherein the connection of step (d) is established by theentity among the device control module or the peer device control modulewhich represents a sink device of the connection.
 6. Method according toclaim 1, wherein the second sub-network is of the UPnP type and whereinstep (c) comprises: the step of instructing Connection Managers of thebridge device and the UPnP device represented by the device controlmodule to prepare for connection; the step of setting up a connection onthe UPnP sub-network between the bridge device and said UPnP device; andthe step of configuring an internal connection of the bridge device tolink the connection on the UPnP sub-network with a connection on thefirst sub-network.
 7. Method according to claim 1, wherein the secondsub-network is of the UPnP type and wherein step (d) comprises: the stepof instructing Connection Managers of the UPnP devices represented bythe device control module and the peer device control module to preparefor connection; and the step of establishing a connection on the UPnPsub-network of the two UPnP devices.
 8. Method according to claim 1,wherein said data received from the stream manager comprises a SEIDidentifier of the peer device control module.
 9. Method according toclaim 1, wherein the first sub-network is a HAVi network.
 10. Method forestablishing a connection between a first and a second device by a HAViStream Manager, wherein it comprises the steps of: (a) determiningidentifiers of device control modules of the first and second devices;(b) inserting said identifiers into a message for instructing a devicecontrol module to perform internal connections.
 11. Method according toclaim 10, wherein said message is ‘Dcm::Connect’.
 12. Method accordingto claim 10, further comprising the step of checking whether the devicecontrol modules are of the legacy type and have a same deviceidentifier, and only in the negative reserving connection resources onthe HAVi network.
 13. Method according to claim 10, further comprising astep (c) of checking whether the device control modules are of thelegacy type and have a same device identifier, and wherein, in theaffirmative the message instructs the device control modules toestablish a non-HAVi connection, and in the negative the messageinstructs the device control modules to establish a connection between adevice on the HAVi network and a legacy device.
 14. Method forestablishing a connection between a first and a second device in anetwork comprising a bridge device connecting a first sub-network to asecond sub-network, wherein it comprises the steps, at the level of adevice control module of the first device hosted by the bridge device,of: (a) determining whether the first and second devices are ondifferent sub-networks or whether the first and second devices are onthe second sub-network; and (b) in the first case, establishing aconnection directly between the first and the second devices; and (c) inthe second case, establishing at least a connection between the bridgeand the second device.
 15. Method according to claim 14, wherein thefirst sub-network is a HAVi sub-network.